Elasticity is a key requirement and promise of cloud computing. It means that as the user demand for different services varies, the infrastructure providing these services expands and shrinks dynamically to accommodate the changing demand on one side while ensuring efficient resource utilization on the other. The infrastructure is expected to do so without impacting the availability of the services; that is, without causing any service outage. In general, the cloud services are believed to be “available” all the time.
However, today's cloud solutions generally address service availability and continuity at the level of virtual machines (VMs). When addressing the cloud elasticity at the VM level, the VM resources are either increased or decreased as needed. New VMs are created with the same applications on them and expected to serve the same users.
A solution addressing the domain of service availability and continuity is laid out in the Service Availability (SA) Forum specifications. In particular, it is the Availability Management Framework (AMF) which manages the availability of application services in the context of application failures. The specifications also define other middleware services providing a variety of tools (such as checkpoints, notifications, etc.) that an application developer can use to achieve this primary goal of service availability. The SA Forum specifications, however, do not explicitly address elasticity.
According to the SA Forum specifications, an AMF implementation performs its task (i.e., availability management) based on a configuration, which is a model that describes the applications in terms of AMF concepts. Based on the configuration, AMF manages the applications to maintain the availability of their services in spite of possible application component failures. To avoid single points of failure, an AMF configuration includes redundancy of the service provider entities (such as components and service units) that in case of failure take over the service provisioning under the orchestration of AMF. AMF configuration is managed via the Information Model Management service (IMM). IMM and the other SA Forum services are designed to support AMF and AMF managed applications.
The AMF specification specifies a set of redundancy models that define their appropriate strategies for protecting the services by the redundant provider entities. The redundancy models specify for AMF a scope—a pool of service providers—among which AMF can adjust the service assignments to compensate for any service provider entity going out of service. The event of a service provider going out of service can be perceived as shrinking the resource pool that AMF can use to provide the service. When the service provider entities are repaired and become available, AMF can use them again thus the pool expands. That is, AMF ensures the service provisioning while the resources scale up and down due to their operational status. The operational status of the service provider entities is a runtime feature that AMF evaluates on a continuous basis.
The elasticity addressed herein is driven by changes in user demands and resource utilization as opposed to failures and repairs addressed in the AMF specification. Currently, AMF does not react automatically to workload changes. As previously mentioned, the VM-level solutions propose to create new VMs in response to workload increase. However, AMF operates based on a configuration that it uses to manage the life-cycle of the application components, which means that an AMF managed application will not start just because a new VM becomes available. Furthermore, because AMF controls service assignments to application components, the workload associated with an application component cannot be associated with a VM as AMF may move the workload around as necessary. Thus, the existing VM-level solutions are deficient in addressing the elasticity issues arising from workload changes in an AMF managed application.